Background

Observers array is a big-endian array with the oracle id (0...N-1) of the oracle that made the corresponding observation in the observation array. So [0x4, 0x1, 0x3, 0x0, 0x2, 0x0, ... , 0x0] shows the observations were given in the order of oracles with ids 4, 1, 3, 0, 2 (given 5 oracles). The rest of the byte array is 0x0 because there are only 5 oracles

Problem

There was a small bug where if the first byte (big-endian) is 0x8 (oracle-id 8) or higher, the observers byte will cause felt overflow.

this happens 1/8 * (N - 8) where N is the total number of oracles we have.

it does not affect feed uptime because if it occurs, the current round will fail and a new round will be kicked off after and succeed, but it is a serialization error that needs to be fixed bc it causes rounds to fail.

Solution

the fix is to 0x01-pad the first byte (big-endian) so that the new byte array represents at most 2^249 - 1 values which is definitely less than https://docs.starknet.io/architecture-and-concepts/cryptography/p-value/

Deserializing

If you are reading observers on-chain, to differentiate this new encoding scheme from the original encoding scheme, check if, within the first N + 1 bytes (where N is the length of the observations array), 0x01 occurs twice, once at the 0th index and at index 1 to N.

^ the above is only really necessary during the blocks in which chainlink nodes are being upgraded

In the event that oracle id 1 has not reported, technically you cannot differentiate between the two cases so you can fallback to the new encoding scheme. Should not be an issue because the window for the upgrade will be small so and presumably after some block number you can always be sure it is using the new encoding scheme